Modern processing devices for executing software code often support multithreaded approaches, in which a single program is split into at least two separate threads that are executed independently. It is also possible that the processing device comprises more than one processing units, each unit having one or more cores for executing code. In this case, the separate threads can be independently executed in the same time period on different cores. During execution, it is possible that one thread tries to access a shared resource, e. g. a shared memory or an I/O-device, which is already accessed by another thread. This situation is called a data race or race condition and results when a shared resource is accessed by two or more concurrent threads without proper synchronisation to constrain the ordering of the accesses, and at least one of the accesses is a write operation. This means that the results of the threads may vary depending on the access sequence. Such behaviour is normally unwanted, and in order to avoid race conditions, many processing devices support synchronisation primitives such as semaphores in their hardware. The implementation of synchronisation primitives is usually available within an Operating System or dedicated libraries and is supported by dedicated hardware mechanisms.
For example, U.S. Pat. No. 7,757,237 B2 describes the synchronisation of threads in a multithreaded computer program using a dedicated hardware table that is updated with addresses of shared variables upon execution of load/store instructions. EP 1 591 895 A2 describes a method based on maintaining a virtual clock by each thread and thread segments. A method based on the comparison of the variable content with a local copy is shown in U.S. Pat. No. 7,366,965 B2, and a method using a compiler configured to generate code with a software transactional memory system is known from US 20090328019 A1. U.S. Pat. No. 7,549,150 B2 extends a classic hardware-based lockset approach for reporting fewer false positives in the fork and join context. In addition to the dynamic approach described above, there are also other approaches to prevent a race condition at mission time or run time. U.S. Pat. No. 7,243,319 B2 uses a static analysis of hardware circuits to detect race conditions. The detection of race conditions using a test suite during software testing phase is known from U.S. Pat. No. 6,851,075 B2, and US 20080109641 A1 describes a method for defining a set of tests which can be used for testing the program in the software testing phase. A method for detection of code deficiencies, such as potential race conditions, is given in US 20060053422 A1. EP 0864975 A2 describes a process wherein a sequence of lock acquire and lock release commands is analysed to record state information of locking order for detecting locking conditions. Applicant's co-pending application WO 2010/038780 A1 describes a method which comprises storing a seed value to a first global variable D; identifying a race condition when a second global variable A does not equal a first predefined value, storing a second predefined value to the second global variable A, identifying a race condition when the first global variable D does not equal the seed value; accessing a shared resource, and storing the first predefined variable V1 to the second global variable A. This known method requires write access to a common memory from multiple concurrent tasks.